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Description 

BACKGROUND OF THE INVENTION 

s The present application is directed to application programmers interfaces (API) for programmer applications for 
communications systems. 

As set forth in U.S. Patent No. 5,499,365, full incorporated herein by reference, object oriented programming sys- 
tems and processes, also referred to as "object oriented computing environments," have been the subject of much 
investigation and interest. As is well known to those having skill in the art, object oriented programming systems are 

10 composed of a large number of "objects." An object is a data structure, also referred to as a *frame," and a set of oper- 
ations or functions, also referred to as "methods," that can access that data structure. The frame may have "slots." each 
of which contains an "attribute" of the data in the slot. The attribute may be a primitive (such as an integer or string) or 
an object reference which is a pointer to another object. Objects having identical data structures and common behavior 
can be grouped together into, and collectively identified as a "class." 

is Each defined class of objects will usually be manifested in a number of Instances". Each instance contains the par- 
ticular data structure for a particular example of the object. In an object oriented computing environment, the data is 
processed by requesting an object to perform one of its methods by sending the object a "message". The receiving 
object responds to the message by choosing the method that implements the message name, executing this method 
on the named instance, and returning control to the calling high level routine along with the results of the method. The 

20 relationships between classes, objects and instances traditionally have been established during "build time" or genera- 
tion of the object oriented computing environment, i.e., prior to "run time" or execution of the object oriented computing 
environment. 

In addition to the relationships between classes, objects and instances identified above, inheritance relationships 
also exist between two or more classes such that a first class may be considered a "parent" of a second class and the 
25 second class may be considered a "child" of the first class. In other words, the first class is an ancestor of the second 
class and the second class is a descendant of the first class, such that the second class (i.e., the descendant) is said 
to inherit from the first class (i.e., the ancestor) The data structure of the child class includes all of the attributes of the 
parent class. 

Object oriented systems have heretofore recognized "versions" of objects. A version of an object is the same data 
as the object at a different point in time. For example, an object which relates to a "work in progress", is a separate ver- 
sion of the same object data which relates to a completed and approved work. Many applications also require historical 
records of data as it existed at various points in time. Thus, different versions of an object are required. 

Two articles providing further general background are E.W. Dijkstra. The Structure of "THE" Multi programming 
System, Communications of the ACM, Vol. 11, No. 5, May 1968, pp. 341-346, and C.A.R. Hoare, Monitors: Operating 

35 Systems Structuring Concepts, Communications of the ACM, Vol. 1 7, No. 1 0, October, 1 974, pp. 549-557, both of which 
are incorporated herein by reference. The earlier article describes methods for synchronizing using primitives and 
explains the use of semaphores while the latter article develops Brinch-Hansen's concept of a monitor as a method of 
structuring an operating system. In particular, the Hoare article introduces a form of synchronization for processes and 
describes a possible method of implementation in terms of semaphores and gives a proof rule as well as illustrative 

40 examples. 

As set forth in the Hoare article, a primary aim of an operating system is to share a computer installation among 
many programs making unpredictable demands upon its resources. A primary task of the designer is, therefore, to 
design a resource allocation with scheduling algorithms for resources of various kinds (for example, main store, drum 
store, magnetic tape handlers, consoles). In order to simplify this task, the programmer tries to construct separate 

45 schedulers for each class of resources. Each scheduler then consists of a certain amount of local administrative data* 
together with some procedures and functions which are called by programs wishing to acquire and release resources. 
Such a collection of associated data and procedures is known as a monitor. 

The adaptive communication environment (ACE) is an object-oriented type of network programming system devel- 
oped by Douglas C. Schmidt, an Assistant Professor with the Department of Computer Science, School of Engineering 

60 and Applied Science, Washington University. ACE encapsulates user level units and WIN32 (Windows NT arid Win- 
dows 95) OS mechanisms via type-secured, efficient and object-oriented interfaces: 

• IPC mechanisms - Internet-domain and UNIX-domain sockets, TLI, Named pipes (for UNIX and Win 32) and 
STREAM pipes; 

55 • Event multiplexing - via selectO and poII() on UNIX and WaitForMultipleObjects on Win 32; 

• Solaris threads. POSIX Pthreads. and Win 32 threads; 

• Explicit dynamic linking facilities - e.g., dlopen/dlsym/dlclose on UNIX and LoadLibrary/GetProc on Win 32; 
Memory-mapped files; 
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• System VIPC - shared memory, semaphores, message queues; and 

• Sun RPC (GNU rpc++). 

In addition, ACE contains a number of higher-level class categories and network programming frameworks to inte- 
grate and enhance the lower-level C++ wrappers. The higher-level components in ACE support the dynamic configura- 
tion of concurrent network daemons composed of application services. ACE is currently being used in a number of 
commercial products including ATM signaling software products, PBX monitoring applications, network management 
and general gateway communication for mobile communications systems and enterprise-wide distributed medical sys- 
tems. A wealth of information and documentation regarding ACE is available on the worldwide web at the following uni- 
versal resource locator: rtttpy/www.cs.wusti.edu/...schmi^^ 

The following abbreviations are or may be utilized in this application: 

• Thread - a parallel execution unit within a process. A monitor synchronizes, by forced sequentialization, the parallel 
access of several simultaneously running Threads, which all call up functions of one object that are protected 
through a monitor. 

• Synchronizations-Primitive - a means of the operating system for reciprocal justification of parallel activities. 

• Semaphore - a Synchronizations-Primitive for parallel activities. 

• Mutex - a special Synchronizations-Primitive for parallel activities, for mutual exclusion purposes, it includes a crit- 
ical code range. 

• Condition Queue - an event waiting queue for parallel activities referring to a certain condition. 

• Gate Lock - a mutex of the monitor for each entry-function, for protection of an object, for allowing only one parallel 
activity at a lime to use an Entry-Routine of the object. 

• Long Term Scheduling - longtime delay of one parallel activity within a condition queue or event waiting queue for 
parallel activities. 

• Broker - a distributor. 

In addition, the following acronyms are or may be used herein: 

AFM Asynchronous Function Manager 

SESAM Service & Event Synchronous Asynchronous Manager 

PAL Programmable Area Logic 

API Application Programmers Interface 

IDL Interface Definition Language 

ATOMIC Asynchron Transport Optimizing observer-pattern-like system supporting several Modes (client/server - 

push/pull) for an IDL-less Communication subsystem, described herein 

XDR External Data Representation 

I/O Input/Output 

IPC Inter Process Communication 

CSA Common Software Architecture (a Siemens AG computing system convention) 

SW Software 

SUMMARY OF THE INVENTION 

The present invention provides a location and protocol transparent object oriented communication system that 
implicitly encodes and decodes transferred data, if connected peers reside on host with different internal data represen- 
tation. In that regard, the invention provides an Asynchronous Transport Optimizing Observer- Pattern-Uke system 
Supporting Several Modes for an Interface Definition Language- less Communication Subsystem (ATOMIC) as well as 
an application programming interface therefor. However, the data structure must be identical to that expected by the 
supplier. 

In an embodiment, the invention provides an object oriented communication system on a computer platform, com- 
prising: 

means for supporting external data representation without an interface definition language; means for propagating 
events in both push and pull communication modes and selecting which mode is used for a given connection: 
means for distributing events; and means for server processing pattern management. 

In an embodiment, the means for supporting external data representation without an interface definition language 
comprises means for implicitly coding and decoding transferred data. 
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In an embodiment, all communication end points that use the same address are logically connected. 

In an embodiment, there is provided a hook routine which called at the supplier side before data is sent and a hook 
routine which is called before data is stored in a target object, both hook routines called with an environment string as 
an argument, both hook routines influencing data transfer. 
s In an embodiment, the invention further provides means for performing XDR encoding and decoding. 

In an embodiment, the invention further provides a macro routine which makes a class accessible to a communi- 
cation end-point. 

In an embodiment, the macro routine makes the class accessible via the communication end point by declaring 
inserter and extractor operators of the communication systems internal encoder/decoder class as friends, and imple- 
10 menting short member functions and one member function pointer into the class. 

In an embodiment, the invention further provide a macro routine which defines a subset of data members that are 
to be transferred and informs the underlying system as to how to deal with pointers and vectors. 

In an embodiment, the macro routine has two arguments, a dass name and a list of white space separated macro 
routines, one such macro routine for each transferable data member. 
15 In an embodiment, the invention provides a supplier class associated with a pattern string in order to transfer com- 
ponent classes to consumers associated with the same pattern string residing on a host. 

In an embodiment, the supplier class is a template class and can only exist in conjunction with a concrete compo- 
nent class. 

In an embodiment, the invention further provides a consumer class associated with a pattern string in order to 
20 receive component classes in PUSH mode or PULL mode from suppliers associated with the same pattern string resid- 
ing on hosts; 

in an embodiment, the consumer class is a template class and can only exist in conjunction with a concrete com- 
ponent class. 

In an embodiment, the invention provides an object oriented communication system on a computer platform, com- 
25 prising; 

means for Supporting external data representation without any interlace definition language said means for sup- 
porting external data representation without an interface definition language comprises means for implicitly encod- 
ing and decoding transfer data; means for propagating events in both push and pull communidatibh modes and 
$d selecting which mode is used for a given connection, including a hook routine called at the supplier side before data 
is sent and a hook routine called before data is stored in a target object, both hook routines called within an envi- 
ronment string as an argument; means for distributing events; and means for server processing pattern manage- 
ment, wherein all communication endpoints that use the same address are logically connected. 

35 In an embodiment, the invention provides an object oriented communication system programmer interface on a 
computer platform, comprising: a first macro routine which makes a class accessible to a communication endpoint by 
declaring inserter and extractor operators of a communication systems internal encoder/decoder class as friends and 
implementing short member functions and one member function pointer into the class; and a second macro routine 
which defines a subset of data members that are to be transferred and informs the underlying system as to how to deal 

40 with pointers and vectors, a second macro routine having two arguments, a class name and a list of white space sepa- 
rated macro routines, one such white space separate macro routine for each transferable data member. 

In an embodiment, the invention provides a supplier class associated with a pattern string in order to transfer com- 
ponent classes to consumers associated with the same pattern string residing on a host. 

In an embodiment, the supplier class is a template class and can only exist in conjunction with a concrete compo- 

45 nent class. 

In an embodiment, the invention further provides a consumer class associated with a pattern string in order to 
receive component classes in PUSH mode or PULL mode from suppliers associated with the same pattern string resid- 
ing on hosts. 

In an embodiment, the consumer class is a template class and can only exist in conjunction with a concrete corn- 
si? ponent class. 

These and other features of the invention are discussed in greater detail below in the following detailed description 
of the presently preferred embodiments with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

Figure 1 illustrates a hardware and software environment. 

Figure 2 illustrates the main components of an object-oriented program from Figure 5 of U.S. Patent No. 
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5.313,629. 

Figure 3 illustrates an example of an inheritance hierarchy to an object oriented platform. 

Figure 4 illustrates use of a setValueO using event propogation or client/server communication without reply. 

Figure 5 illustrates blocking of a setValueO using client/server communication with reply. 

Figure 6 illustrates a nonlocking setValueO using client/server communication with reply - waitFor...(). 

Figure 7 illustrates a nonlocking setValueO using client/server communication with reply - callback 

Figure 8 illustrates blocking getValueO without dataChangedO enabled. 

Figure 9 illustrates sending no reply with dataChangedO enabled. 

Figure 1 0 illustrates sending reply without dataChangedO enabled. 

Figure 1 1 illustrates sending reply with dataChangedO enabled. 

Figure 1 2 illustrates a nonlocking getValueO using waitForMultipleObjects. 

Figure 13 illustrates a nonlocking getValueO using call-back function. 

Figure 14 illustrates dispatching dataChangedO to handle incoming data. 

Figure 15 illustrates blocking a PULL mode getValueO using NOWAIT flag. 

Figure 16 illustrates dispatching dataChangedO to handle pulled data. 

COPENDING APPLICATIONS 

The following commonly assigned copending applications are fully incorporated herein by reference: 



Title 


Application NUMBER 


Filing Date 


Attorney Docket No. 


MONITOR SYSTEM FOR SYNCHRONIZATION OF 
THREADS WITHIN A SINGLE PROCESS 

SERVICE AND EVENT SYNCHRONOUS/ASYN- 
CHRONOUS MANAGER 

SOFTWARE ICS FOR HIGH LEVEL APPLICATION 
FRAMEWORKS 






GR96P3106E 
GR96P3107E 
GR 96 P 3109 E 



PETAILEP DESC RIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS 



As stated above, the present invention (ATOMIC) provides a communication system application programmers inter- 
face (API) as well as basic mechanisms of the system itself. 

Again referring to U.S. Patent No. 5,499365, in an object oriented computing environment, work is accomplished 
by sending action request messages to an object which contains data. The object will perform a requested action on 
the data according to its predefined methods. Objects may be grouped into object classes which define the types and 
meanings of the data, and the action requests (messages) that the object will honor. The individual objects containing 
data are called instances of the class. 

Object classes can be defined to be subclasses of other classes. Subclasses inherit all of the data characteristics 
and methods of the parent class. They can add additional data and methods and they can override or redefine any data 
elements or methods of the parent class. An object may be represented schematically, and generally is represented 
herein by a rectangle. The upper rectangle contains the data structure represented by a frame having slots, each of 
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which contains an attribute of the data in the slot The lower rectangle indicates the object's methods which encapsulate 
the frame and which are used to perform actions on the data encapsulated in the frame of the upper rectangle. 

Figures 1,2 and 3 are reproduced herein from U.S. Patent No. 5,499.365. The following description relating thereto 
is derived from that patent 

5 Referring now to Figure 1 , a hardware and software environment in which the present invention operates will now 
be described. As shown in Figure 1 , the present invention is a method and system within an object oriented computing 
environment 1 1 operating on one or more computer platforms 12. It will be understood by those having skill in the art 
that computer platform 12 typically includes computer hardware units 13 such as a central processing unit (CPU) 14, a 
main memory 15 and an input/output (I/O) interface 1 6. and may include peripheral components such as a display ter- 

10 minal 21 , an input device 22 such as a keyboard or a mouse, nonvolatile data storage devices 23 such as magnetic or 
optical disks, printers 24 and other peripheral devices. Computer platform 12 also typically includes microinstruction 
codes 26 and an operating system 28. 

As shown in Figure 1, object oriented computing environment 11 operates on computer platform 12. It will be 
understood by those having skill in the art that object oriented computing environment may operate across multiple 

15 computer platforms. Object oriented computing environment 1 1 is preferably written in the C++ computer programming 
language. The design and operation of computer platforms and object oriented computing environments including that 
of an object manager, are well known to those having skill in the art and are described, for example, in U.S. Patent No. 
5,265,206 issued November 23, 1993 to Abraham, et at. entitled "A Messenger and Object Manager to Implement an 
Object Oriented Environment"; and U.S. Patent No. 5,161,225 to Abraham, et al., entitled "Persistent Stream for 

20 Processing Time Consuming and Reusable Queries in an Object Oriented Database Management System; U.S. Patent 
No. 5,151,987 to Abraham, et at, entitled "Recovery Objects in an Object Oriented Computing Environment"; and U.S. 
Patent No. 5,161,223 to Abraham, entitled "Resumeable Batch Query for Processing Time Consuming Queries in an 
Object Oriented Database Management System", the disclosures of which are hereby incorporated herein by refer- 
ence, and in numerous textbooks such as Object Oriented Software Construction by Bertrand Meyer, published by 

25 Prentice Hall in 1988, the disclosure of which is incorporated herein by reference and the publication referred to above 
in the Background section. 

Referring now to Figure 2, which is a reproduction of Figure 5 of U.S. Patent No. 5,313,629. the main components 
of an object oriented program (11, Figure 1 ) will be described. A detailed description of the design and operation of an 
object oriented program is provided in "Object Oriented Software Construction", by Bertrand Meyer, published by Pren- 

30 tice Hall in 1988, the disclosure of which is incorporated herein by reference. 

Referring.to Figure 2, a typical object oriented computing environment 1 1 includes three primary components: a 
Messenger 51, and Object Management Table 52 and a Loaded Classes Table 53. The Messenger 51 controls com- 
munication between calling and called messages, Object Management Table 52 and Loaded Classes Table 53. Object 
Management Table 52 contains a list of pointers to all active object instances. The Loaded Classes Table 53 contains 

35 a list of pointers to all methods of active object classes. 

Operation of the Object Oriented Program 1 1 will now be described for the example illustrated in Figure 2, in which 
Methods A (block 54) of an object sends a message to method B (block 55) of an object. Method A sends a message 
to Method B by calling Messenger 51 . The message contains (1 ) an object reference of the instance to receive the mes- 
sage, (2) the method the object instance is requested to perform on the data it encapsulates, and (3) any parameters 

40 needed by the receiving method. Messenger 51 obtains a pointer to the data frame 56 of the instance object specified 
by Method A, by siearching Object Management Table 52 for the instance object If the specified instance object cannot 
be found, Object Management Table 52 adds the instance object to the table and calls the instance to materialize its 
data from the database. 

Once in the instance table, Object Management Table 52 returns the pointer to the materialized instance object. 
45 Messenger 51 then obtains the address of Method B from the Loaded Classes Table 53. If the instance's class is 
not loaded, the Loaded Classes Table 53 will load it at this time to materialize its data. The Loaded Classes Table 53 
searches for the specified method (Method B) and returns the address of the method to Messenger 51 . 

The Messenger 51 then calls Method B, passing it a system data area and the Parameters from the call made by 
Method A including the pointer. Method B accesses the data frame 56 using the pointer. Method B then returns control 
so to the Messenger 51 which returns control to Method A. 

Figure 3 illustrates an example of an inheritance hierarchy to an object oriented computing platform. As shown, 
three object classes are illustrated for "salesperson", "employee" and "person", where a salesperson is a "kind of" 
employee, which is a "kind or person. In other words, salesperson is a subclass of employee and employee is the 
superclass of salesperson. Similarly, employee is the subclass of person and person is the superclass of employee. 
55 Each class shown includes three instances. B. Soutter, W. Tipp and B.G. Blue are salespersons. B. Abraham, K. Yates 
and R. Moore are employees. J. McEnroe, R. Nader and R. Reagan are persons. In other words, an instance is related 
to its class by an "is a" relation. 

Each subclass "inherits" the frames and methods of its superclass. Thus, for example, a salesperson frame inherits 
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age and hire date objects from the employee's superclass as well as promote methods from the employee superclass. 
Salesperson also includes a unique quota attribute and a pay commission method. Each instance can access all meth- 
ods and frames of its superclass, so that, for example, B.G Blue can be promoted. 

The ATOMIC communication system is a location and protocol transparent object oriented communication system 
that implicitly encodes and decodes transferred data, if the connected peers reside on hosts with different internal data 
representation. 

To that end, all communication endpoints (a/k/a peers) that use the same address - a character string (pattern) - 
are logically connected . The patterns are valid with the network segment the host is connected to. Different name 
spaces may be realized by using a name service for the pattern strings (e.g., by adding the host name and/or the proc- 
ess name to the pattern string). 

The communication system provides one way communication between supplier and consumer peers. 

COMMUNICATION MODES 

15 The ATOMIC communication system supports two communication modes: an event propogation mode, which is 
preferred; and a classic client/server communication mode, which is known from RPC based communication toolkits. 
Table 1 below summarizes a comparison of the event propogation and classic client/server communication modes 



20 


Event Propagation Modes 
m (suppliers) to n (consumers) 


PUSH Mode 


Consumer 
Callback 




Connections 


PULL Mode 


Supplier 
Selection 


25 




Single Push without reply 




Client/Server Communication 


Supplier with Callback and/or 


30 


Modes 


waitFor . . . () 




n (suppliers) to 1 (consumer) 


( ... [REPLY [, Callback] 
[,SynchHandle] ] ) 




Connections 


Consumer with Callback and/or 


35 




waitFor. . . () 








( ... [WAIT [, Callback] 






LSynchHandle] ] ) 



40 

Table 1: Event Propogation and Client/Server Modes 



Event Propogation Mode 

In the event propogation mode one or more suppliers make events known to zero (0) or more consumers, which 
may be interested in this event by using the same pattern string as the supplier(s). Neither acknowledgments nor replies 
50 are supported in this mode because of the arbitrary number of consumers. This mode supports two transfer modes 
described next, the PUSH mode and the PULL mode. 

The PUSH Mode 

55 The PUSH mode - the most common event propogation mode - is a supplier triggered communication. The supplier 
of an event propagates an event that causes the delivery of a dataChangedO method (which is a callback function, 
action routine) - if enabled by the consumer - in the consumer context. It is up to the consumers whether to allow PUSH 
mode events to be queued (such that no event is lost) or not to be queued. 
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The Pull Mode 

The PULL mode is a consumer triggered communication. The consumer fetches incoming events independently of 
the supplier's timing in propagating them. There is no queuing at the consumer's side because every consumer read 
request causes the communication system to get a copy of the latest version of the supplier's data. The internal han- 
dling depends on the queuing flag set (or not set) in the consumer's CsaRemote object. In case of queuing, a "get- 
ValueO" call blocks until the next data structure is provided by the supplier; if queuing is switched off, the "getValueO" 
call returns the contents of the last data structure that were sent by the selected supplier (if any, otherwise an error is 
reported). 

To avoid multiple queries into the same receiver object as the result of a consumer read request, one supplier must 
be selected to get a unique object read. 

Client/Server Communication Mode 

The classic supplier triggered client/sever communication allows one or more clients (suppliers) to connect to one 
(and only one) server (consumer). This n-to-one relationship allows the server to send a reply back to the client on an 
incoming event (message), if this reply was requested by the client (supplier). 

A significant add-on to the standard client/server communication, as known from. RPC is the consumer triggered 
client/server communication. Every event received at the consumer side is queued into the consumer's input queue and 
can be retrieved by calling the getvalueO method (see description below) without getting any callbackO routines dis- 
patched. This feature allows the consumer to process a new event when appropriate without taking care of the restric- 
tions that go along with asynchronous dispatching. 

Location Transparency 

The location of the communication partner (supplier as well as consumer) is fully transparent (i.e. as to whether it 
is located within the same process, on the same host, or on a remote host). 

The ATOMIC communication system decides which protocol provides the best performance for the particular con- 
nection. 

The user can specify a shared memory flag as an attribute to the constructors of the CsaConnectable (supplier) 
and CsaRemote (consumer) objects, and it is treated as a hint to the communication system. 

ENVIRONMENT AND HOOKS 

The Environment String 

The ATOMIC communication system (Msc) transfers data together with additional header information containing 
the sender's peer address, the addressee's peer information, and an optional user specified environment string. The 
data type of the environment is defined in the header file CsaMscOptions.hh as follows: 
const int theCsaMscEnvSize = 32 ; 
typedef char CsaMscEnvType[theCsaMscEnvSize]; 
The environment string can be passed to sender/receiver methods (see CsaConnectable's setValueO/getvalueO 
and CsaRemote's getvalueQ/dataChangedO descriptions below). 

The semantics of the environment string are application specific and defined. The ATOMIC communication system 
passes the environment data without interpretation. 

Adding and Removing Hoo k Routines 

The ATOMIC communication system provides an interface to implement two hook routines, one at the supplier side 
that is called before the data are sent and one at the consumer side, that is called before the received data are stored 
in the target object. The hook routines are of type bod (i.e.. boolean) and are called with one argument, the environ- 
ment string. The hook routines are implemented once per process and are intended to be used by applications that 
modify/interpret implicitly the environment string (e.g. copy thread specific data into the environment string or store the 
environment string as thread specific data). 

The value ("true" or "false") returned by the hook routines influences the data transfer. In that regard, the value 
"true" doesn't change the behavior while value "false": 

• at the supplier side, aborts a setValueQ call without sending the data to the consumers) 
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• at the consumer side, aborts a getValueO call without copying the data to the consumer(s) target object(s) and with- 
out dispatching/notifying the consumer. 

These hook routines may be used for event filtering depending on (implicitly or explicitly specified) environment 
string contents. 

The following sample code shows how the hook routines can be inserted, removed or changed. This sample code 
shows setting supplier and consumer hook routines : 

/ / include options header file 
#include <CsaMscOptions . hh> 

/ / the input (consumer) hook routine 
static bool inHook (CsaMscEnvType & theEnv) { 
return (true) ; 

} 

/ / an alternate input (consumer) hook routine 



static book inHook2 (CsaMscEnvType & theEnv) { 
return (true) ; 

} 

/ / the output (supplier) hook routine 
static bool outHook (CsaMscEnvType & theEnv) { 
return (true) ; 

} 

CsaMscOptions theHooks = {inHook, outHook}; 
/ / set the hook routines 

CsaOsOptDb: ; setOptions (CsaMscOptionName, (void *)& 
theHook) ,* 

/ / read the hook routines 

CsaOsptDb: :getOpt ions (CsaMscOptionName, (void *) & 
theHooks) ; 

/ / modify and update the consumer hook routine 
theHooks . thelnputHook = inHook2; 

CsaOsOptDb: : setOptions (CsaMscOptionName, (void *) & 
theHooks ) ; 



Building Classes and Structures 

Some goals for the design of a communication are: 
• the communication should be protocol transparent, 
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• the communication should be location transparent, 

• the communication should be able to transfer all generic data types supported by the compiler, 

• the application programmer should not have to deal with data representation details such as XDR routines 

• the communication systems restrictions to the class design should be as few as possible. 

To achieve these goals, two macros, discussed below, are provided to the class designer, which macros make the 
class transferrable by the communication system. These macros are referred to herein as the IMPLEMENT_MSC and 
DECLARE_MSC macros. The class definition must be identical for both the supplier and the consumer. Therefore, the 
same header file is included by both communication endpoints; changes of the header file do not cause inconsistencies 
because they are not done in different files. 

The XDR encoding/decoding is performed internally by a communication subsystem (the IMPLEMENT_MSC 
macro must be present and specify all data members to be transferred), if the corresponding communication endpoint 
is located on a host with different internal data representation (different processor architecture). 

The short component class example below shows how to use these macros in nested classes (structures are han- 
dled identically to classes; the DECLAREJvISC macro is inserted in the public (default) section of the structure): 

const int theFloatDimension = 333; 
/ / user class example 1 
class XyzSimpleClass { 
public: 

XyzSiimpleClass () {} 
-XyzSimpleClass () {} 
DECLARE_MSC (Xy z S impl eCl as s ) 
protected: 

int alntVar; 

float aFloatArray [theFloaDimension] ; 

}; 

IMPLEMENT_MSC (SyzSimpleClass, V(alntVar) V (aFloatArray) ) 
/ /user class example 2 
class AbcWithPointers { 
public : 

AbcWithPointers (XyzSimpleClass *thePointer=0) : 

myPointer (thePointer) 

{ dsblDataChanged () ; } 
-AbcWithPointers () {} 

bool dataChanged (CsaMscRcvdFrom from_in, 

CsaMscEnvType fctheEnv) 
{ return (true) / } 
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DECLARE_MSC (AbcWithPointers) 
protected: 

double myDoubleVar ; 

XyzSimpleClass mySimpleClass ; 

XyzSimpleClass *myPointer; 

}; 

IMPLEMENT_MSC (AbcWithPointers, V (myDoubleVar) 
V (mySimpleClass) P (myPointer) 

There is no restriction in the number or size of the data members that are to be transferred. Some compilers-pre- 
processors, however, limit the size of macro expansions. 

The DECLARE_MSC macro 

The DECLARE_MSC macro makes the class accessible by a communication endpoint (CsaConnectabie = supplier 
or CsaRemote = consumer) by declaring the inserter/extractor operators of the communication system's internal 
encoder/decoder class as friends, and implementing a few very short member functions (the enable/disable dataCh- 
angedO method), and one member function pointer (the dataChangedO method itself) into the class. 

The DECLARE_MSC macro must be added to the public section of the class as it inserts the member function 
pointer into the protected section of the class and the member functions into the public section of the class. 

The IMPLEMENT_MSC Macro 

The IMPLEMENT_MSC macro defines the subset of data members that are to be transferred and tells the under- 
lying system how to deal with pointers/vectors. 

The IMPLEMENTJvISC macro must be placed after the class definition (it implements the inserter/extractor oper- 
ators of the communication system's internal encoder/decoder class. 

The IMPLEMENTJvISC macro has two arguments - the class name and a list of white space separated macros; 
one macro for each transferable data member. The V(datamember) macro tells the communication system to treat the 
variable in the argument as a scalar or vector that is to be transferred. 

The P(datamember) macro tells the communication system to dereference the pointer specified in the argument 
and transfer the contents of the class/structure/variable the pointer points to. 

It should be noted that: 

• All variable specification macros (e.g., V() and P0 ... ) build a white space separated list. 

• The user classes may be derived from other classes. The data members of the base class must be specified in the 
IMPLEMENTJvISC macro of the derived class. 

• Classes may be nested (container classes). 

• The transfer is restricted to data members (no VMTs .). 

CsaConnectabie (the supplier) 

A CsaConnectabie is the supplier class associated with a pattern string in order to transfer component classes 
(specified as templates) to consumers) associated with the same pattern string residing on local or remote hosts. 

The class CsaConnectabie is a template class and therefore can only exist in conjunction with a concrete compo- 
nent class. 

A more detailed interface description is provided below and sample code is provided under the heading "Exam- 
ples. " 
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The Constructor 

The constructor takes two arguments: 

• a pattern string which specifies the name of the communication endpoint, 

• an attribute mask (local/shared memory has to be used for message buffering) 

The CsaConnectable establishes the connection to the underlying basic communication system and allocates a 
generic SESAM (reference should be made to Application Attorney Docket No. GR 96 P 3107, incorporated herein by 
reference) slot for event notification. 

Data Transfer 

Data transfer is initialized by a call to member function setValueO. The user object specified in the argument list 
contains the data to be transferred. 

In most cases, the event propagation mode will be used. In this mode, only one argument must be supplied - a ref- 
erence to the user class object that contains the data to be transferred. 

Both, the PUSH mode and the PULL mode interface do not differ from the suppliers point of view. Reference should 
be made to Figure 4 wherein setValueO using event propogation or client/server communication without reply is illus- 
trated. 

In case of client/server communication, some more information must be passed to setValueO- Because only one 
server can be connected to the supplier, one of the existing consumers must be selected as the server. This can be per- 
formed by calling getConsumersO, selecting the appropriate consumer and passing the consumer informations (class 
CsaMscPeerlnfo) as an argument to setValue. 

In the client/server mode, a reply from the server (consumer) might be expected. If the reply argument is specified, 
the call to setValueO blocks until the reply is received. Reference should be made to Figure 5 wherein blocking of set- 
ValueO using client/server communication with reply is illustrated. 

The last data set transferred through the CsaConnectable can be reread via getValueO. The getValueO, unlike the 
getValueO method of CsaRemote, never blocks because the requested data are already present (or not; in this case an 
error status will be returned). Therefore, not asynchrony is provided in the CsaConnectable's getValueO interface. 

If blocking calls (client/server mode only) to setValueO are not acceptable, the setValueO method can be performed 
in a separate thread. This is done by implicitly using the SESAM's dynamic slot mechanism. The synchronisation 
(again, reference should be made to Application Attorney Docket No. GR 96 P 3107 E for a more detailed description 
of these aspects of SESAM ) can be realized in two different ways - waiting for a SynchHandle (returned by setValueO) 
(see Figure 6 illustrating nonlocking setValueO using client/server communication with reply - wartFor.„0 and/or get- 
ting a callback method (must be passed to setValueO) dispatched after completion of setValueO (see Figure 7 illustrat- 
ing nonlocking setValueO using clientfserver communication with reply -callback. 

It should be noted that asynchronous setValueO calls are only supported if a reply was requested. 

In the constructor of CsaConnectable, a generic SESAM slot is allocated, and the SynchHandle associated with 
this slot is stored as a CsaConnectable's private data. This SynchHandle - in this context called notification handle - can 
be obtained by calling the method getNotificationHandleO. This handle can be used for example in watchdog threads 
that keep track of replies that are initiated by setValueO calls of other threads without knowledge of the setValueO's 
arguments. 

Data Processing 

The data members of the user class object are copied by an i/o stream-like encoder/decoder into a message buffer, 
which is passed to the underlying communication system. The CsaConnectable holds always the latest message buffer 
for subsequent getValueO calls and to grant requests from a PULL mode consumer. There is no 1 to 1 relationship 
between this message buffer in the output queue and a specific user class object if more than one object has been 
transferred through this CsaConnectable by one or more threads. 

Design Restrictions 

CsaConnectabies (suppliers) may be located on a stack, allocated from a heap or stored in a global address space. 
CsaConnectables in shared memory are not supported. 

There must not be classes derived from class CsaConnectable. Containment can be used instead. 
There are no restrictions on the lifetime of the CsaConnectable. 
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CsaRemote (Consumer) 

CsaRemote is the consumer class associated with a pattern string in order to receive component classes (specified 
as templates) in PUSH mode or PULL mode from supplier(s) associated with the same pattern string residing on local 
5 or remote hosts. 

The class CsaRemote is a template class and therefore can only exist in conjunction with a concrete component 
class. 

The Constructor 

10 

The constructor takes two arguments: a pattern string which specifies the name of the communication endpoint; 
and an attribute mask specifying: 

a) whether a shared/local memory has to be used for message buffering, 
15 b) whether or not an incoming message must be queued, and 
c) the CsaRemote (consumer) to select the PUSH/PULL mode. 

The CsaRemote establishes the connection to the underlying basic communication system and allocates a generic 
SESAM (see SESAM API description, copending Application Attorney Docket No. GR 96 P 3107 E) slot for event noti- 
20 fication. 

Data Transfer 

For the consumer side there are two modes of operation, the event propagation containing the PUSH and PULL 
25 modes as well as the client/server communication (supplier and consumer triggered). 

The supplier triggered modes - event propagation PUSH mode and the clienVserver mode - are very similar from 
the consumer's point of view; the only difference is the reply that will be returned to the supplier (if requested) in cli- 
ent/server mode. Common to both modes is the dispatching scheme and the blocking/nonblocking getValueO (receive) 
calls. 

30 Consumer triggered mode - event propagation PULL mode - is different from the supplier triggered mode in copying 
the last data set (that will always be kept by the supplier) by every call to getValueO - regardless whether the supplier's 
data changed or didnl change between two calls to getValueO- 

Data Filter Method dataChanged 

35 

The DECLARE_MSC macro adds a data filtering and event dispatching mechanism to the user's component class. 

The designer of the user component class can add a method (in this document always named dataChangedO) to 
his class, that can be enabled or disabled at runtime. This method is - if enabled - implicitly called after copying the 
received data into the target object - regardless whether the data are received by a synchronous/asynchronous call to 
40 getValueO or by enabling the dispatching with setCalibackObjectO- In the latter case, the action routine that will get dis- 
patched is the dataChangedO member function. There are two arguments passed to the dataChangedO method, a 
mask of type CsaMscRcvdFrom which specifies the location of the sender (same thread, same process but different 
thread, other process on same host or process on a remote host) (see SESAM API description) and the environment 
string, 

45 In client/server mode, the return value of dataChangedO is returned to the supplier (client) together with the thread 
specif ic error object, if a reply was requested. 

The great advantage of dispatching a member function of the user class is the accessibility of all data members by 
the dispatched function. 

The dataChangedO method is enabled by invoking the user class method: 

50 



55 
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void enblDataChanged ( 
bool (userclass : ;*f ) (CsaMscRcvdFrom, 

CsaMscEnvType & 

) 

); 



The dataChangedO method is disabled by invoking the user class method void dsWDataChanged(void). 
Both methods are implemented by the macro DECLAREJvlSC. 

It should be noted that the dataChangedO method always should explicitly disabled or enabled in the constructor 
of the user class to avoid uninitialized member function pointer. Toggling between enabled and disabled state is possi- 
ble at runtime. 

Supplier Triggered Event Processing 

The most simple case is just calling getValueO with one argument, the reference to a user object as the receiver 
buffer without enabling the dataChangedO method. 

The object getValueO blocks until data are available for reading. Reference should be made to Figure 8 which illus- 
trates blocking getValue without dataChanged enabled. 

If the dataChangedO method is implemented and enabled, it is invoked after reading the incoming data and before 
returning to the caller of getValueO- Reference should be made to Figure 9 which illustrates blocking getValue with 
dataChanged enabled. 

In client/server mode, the supplier may request a reply, if no dataChangedO method is implemented and enabled, 
the reply will be delivered with and have the status of "success" after copying the incoming data into the target object. 
In that regard, reference should be made to Figure 1 0 which illustrates sending a reply without dataChangedO enabled. 
If the dataChangedO method is implemented and enabled, the reply will be delivered after return from dataChangedO 
passing the return status and, if dataChangedO returned 'false', the thread specific error object back to the supplier. In 
that regard, reference should be made to Figure 1 1 which illustrates sending a reply with dataChangedO enabled. 

As described for CsaConnectable, the blocking invocation can be performed in a separate thread implicitly using 
SESAM's dynamic slot mechanism. The synchronization (see detailed description in commonly assigned and copend- 
ing application Attorney Docket No. GR 96 P 31 07 E) can be realized in two different ways - waiting for a SynchHandle 
(returned by getValueO) (see Figure 12 which illustrates nonlocking getValueO using waitForMultipleObjects) and/or 
getting a call-back method (must also be passed to setValue 0) dispatched after completion of setValue() (see Figure 
13 which illustrates nonlocking getValueO using a callback function). 

Many applications are event driven or have more than one input event to wait for. These applications cannot block 
in a single getValueO; they need to get dispatched after arrival of data in one or more CsaRemote objects. This appli- 
cations can declare an object as the receiver object for the specified CsaRemote object using the dataChangedO 
method as the callback method. The dataChangedO method is dispatched from the main dispatcher as long as the 
input queue contains unread data, similar to the RPC action routine (see Figure 14 which illustrates dispatching 
dataChangedO to handle incoming data). At invocation time of dataChangedO the data are already stored in the spec- 
ified object. Reply handling is similar as described for getValueO calls with dataChangedO enabled. 

It should be noted that the dataChangedO method must be enabled before invoking setCallbackObjectQ. 

After enabling the dataChangedO method as the dispatcher for incoming events, no further getValueO calls are 
possible for this CsaRemote object. 

In some cases it may be of interest to be notified every time data on one or more CsaRemote objects arrive. The 
application process then would call the method waitForMultipleObjectsO on the notification handle(s) of the CsaRemote 
object(s) of interest and invoke for every signaled CsaRemote object the getValueO method with the flag "NOWAIT", as 
long as data are available. 

Consumer Triggered Event Processing 

In event propagation PULL mode, the consumer triggers the receiving of messages from supplier(s). To get only 
one data set for the pull request, one specific supplier must be selected. The selection is done by calling the method 
getSuppliersQ, selecting one of the suppliers and calling the method getValueO for the selected supplier. 
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The CsaRemote dass provides two different ways of pulling data from the consumer - request a data set regardless 
if it was yet read by a previous call to getValueO (by calling getValueO with the flag "NOWAIT") or request a new version 
of the data set (by calling getValueO with the flag "WAIT which means wait for a new update by the supplier) (see Fig- 
ure 15 which illustrates blocking PULL mode getValueO using the NOWAITflag). 
s In the latter case the request for a new update is queued at the supplier's CsaConnectable until the next setValueO- 
This set ValueO causes all queued requests to be granted, regardless if they are queued by one or more CsaRemotes 
(i.e. if more than one request from one CsaRemote is pending at the same CsaConnectable, the setValueO method 
grants all requests!). 

The asynchronous functionality - passing the getValueO invocation to SESAM's dynamic slots and waiting for com- 
ic pletion and/or forcing a callback function to be dispatched, respectively - is similar to that of the PUSH model . 

The dispatching of the dataChangedO method enabled by a previous call to setCallbackObjectO is slightly different 
by means of initiator of the callback. In PULL mode the dataChanged is dispatched due to the supplier's response on 
a consumer's getvalueO call (see Figure 13 which illustrates dispatching datachangedQ to handle pulled data). 

is Replies in Client/Server mode 

As described above, replies are possible in clientfserver mode only For the processing of replies, see Table 2 
below. In Table 2, the entry of an "X" means "not of concern." 
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Notes: (1) Consumer triggered event event processing. 

(2) Supplier triggered event event processing. 

(3) If the queue is full, the supplier will block un- 
til the consumer dequeues at least one event. 

Table 2: Reply Behavior 
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Data Processing 

All incoming data are queued into the input queue of the consumer. In the case of PUSH mode consumers that 
specify the attribute "NOTQUEUED" to the constructor, the input queue has a maximum length of 1 message buffer, 
which will be overwritten by a new incoming event. 

The data members of the user class object are copied by an i/o stream-like encoder/decoder from a message 
buffer, which is queued to the input queue of the CsaRemote, to the user class object 

There is no 1 to 1 relationship between this message buffer in the output queue and a user class object, rf more 
than one object has been transferred through this CsaRemote. 

Design Restrictions 

CsaRemote objects (consumers) may be located on a stack, allocated from a heap or stored in a global address 
space. CsaRemotes in shared memory are not supported. 

There must be no classes derived from class CsaRemote. Instead, one must use containment 

There are no restrictions on the lifetime of a CsaRemote object. 

The user class object's lifetime must not be less than the lifetime of the CsaRemote. 

In summary, the principal new approach of the invention is the novel and inventive combination of all the following 
features within a single homogenous package: 

object oriented 

supports external data representation without the need of an Interface Definition Language 
Event-Propagation for Push&Pull-Modes 
Client-Server Communication with reply 
full asynchronous Support 
multithreaded and multithreadsafe 

Layering between Application- View and Implementation- View 
transparency of locations and protocols and according optimizations 

use of a server process for pattern-management only in the registration phase, but never in the Transport phase 
a fully distributed (with local optimizations) event propagation mechanism, so no further event propagation mecha- 
nism is necessary throughout a software system. 

Examples 

The following examples illustrate typical usages of CsaConnectaWe (supplier) and CsaRemote (consumer) objects. 
Both, the supplier and the consumer, use the same header file with class definitions. 
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The Header File 
const int theFloatDimension = 333; 
// user class example 1 
class XyzSimpleClass { 
public : 

XyzSimpleClass () {} 

-XyzSimpleClass ( ) { } 

DECLARE_MSC (XyzSimpleClass) 
protected: 

int alntVar ; 

float aFloatArray [theFloatDimension] ; 

}; 

IMPLEMENT J^SC (XyzSimpleClass, V(alntVar) V (aFloatArray) ) 
//user class example 2 
class AbcWithPointers { 
public: 

AbcWithPointers (XyzSimpleClass *thePointer=0) : 

myPointer (thePointer) 
{ dsblDataChanged () ; } -AbcWithPointers (){ } 
bool dataChanged (CsaMscRcvdFrom from_in, 

CsaMscEnvType &theEnv) 
{ return(true) ; } DECLARE_MSC (AbcWithPointers ) 
protected: 

double myDoubl eVar ; 
XyzSimpleClass mySimpleClass; XyzSimpleClass *myPointer 
}; 

IMPLEMENT_MSC (AbcWithPointers # V (myDoubleVar ) 
V (mySimpleClass) 
P (myPointer) ) 
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The Supplier Program 

#include <CsaConnectable.hh> // communication classes 

#include <user.hh> // user class (es) 

// Callback function that notifies the completion of a 

// blocking call to setValueO with reply 

void * callbackFunc (void *) { 

return { (void *) 0) ; 

} 

/* 

* The main program 
*/ 

main(int argc, char **argv) 

{ 

XyzSimpleClass scl; // a simple user class 

AbcWithPointers wpl (&scl) ; // a 
container user class CsaMscPeerlnf o peers; // information 
about consumers 

bool status; // return status for method calls 
CsaSesam: :SynchHandleType Synch; // SESAM's synchronization 

// handle 

// Event Propagation (PUSH mode) 

CsaConnectable <AbcWithPointers> conl ( "push^ode^conn" ) ; 

status = conl. setValue (wpl) ; 

// Event Propagation (PULL mode) 

CsaConnectable <AbcWithPointers> con2 ( "pull_mode_conn" ) ; 
status = con2 . setValue (wpl) ; 

// Client/Server mode (no reply, synchronous completion) Csa- 
Connectable 

<AbcWithPointers> con3 ( "clsv__mode_conn H ) ; status = 

con3 . getConsumers (&peers) ; 

for ( peers. reset () ; peers++ ; ) { 

// . . . select appropriate consumer 

break; 

} 

status = con3 . setValue (wpl, fcpeers) ,* 

// Client/Server mode (reply, synchronous completion) 
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status = con3.setValue(wpi, fcpeers, CsaMscPeer :: Reply) ; 
// Client/Server mode (reply, callback function) 
status = con3 .setValue(wpl, fcpeers, CsaMscPeer :: Reply, 

callbackFunc) ; 

// Client/Server mode (reply, wait for completion) 
status = con3.setValue(wpi, fcpeers, CsaMscPeer: : Reply, 

0, &Synch) ; 

// some code . . . 

// AFM's WaitForMultipleObj ects (1, fcSynch, LOG_AND, 60000) ; 
retuim 0; 

} 

The Consumer Program 

ttinclude <CsaRemote.hh> // communication classes 
#include<user . hh> 
// user class (es) 

// A allback function that notifies the asynchronous comple- 
tion 

// of a call to getValueO . 
void * callbackFunc (void *){ 
return ( (void *) 0) ; 

} 

/* 

* The main program 
*/ 

main(int argc, char **argv) 
{ 

CsaMscPeerlnfo peers; // information about consumers 

CsaSesam: : SynchHandleType Synch; // SESAM's synchronization 

// handle 

bool status; // return status of method calls 

/* 

* Event Propagation (PULL mode) 
V 
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CsaRemote <AbcWithPointers> reml ( "pull_mode_conn" ( 

CsaMscPeer: :PullMode) ; 
XyzSimpleClass scl; // a simple user class AbcWith- 

Pointers wpi(&scl).; // a 

container class 
// first select a supplier 
status = reml.getSuppliers (fcpeers) ; 
for ( peers. reset () ; peers++ ; ) { 

// ... select appropriate supplier 

break; 

} 

// enable the dataChanged method 

wpl.enblDataChanged(AbcWithPointers: : dataChanged) ; 
// get data using synchronous getValueO call 
while (1) { 

status = reml .getValue (wpl, tpeers) ; 

// ... do something 

} 

// get data using asynchronous getValue () call 
status = reml .getValue (wpl, fcpeers, CsaMscPeer :: Wait, 

callbackFunc) ; 

while (1) { 

status = reml. get Value (wpl, fcpeers, CsaMscPeer :: Wait, 

0, &Synch) ; 

// ... do something 

// SESAM's WaitForMultipleOb- 
jects (1, fcSynch, LOG_AND, 60000) ; 
} 

* Event propagation - PUSH model 
V 

CsaRemote <AbcWithPointers> rem2 ( "pull_mode_conn" , 

CsaMscPeer: :PushMode) ; 
XyzSimpleClass sc2; // a simple user class AbcWithPointers 

wp2 (&sc2) ; // a 
container user class 
// Enable the dataChanged method 
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wp2 .enblDataChanged (AbcWithPointers : : dataChanged) ; 

// First get some data using synchronous getValueO call 

status = rem2 .getValue (wp2) ; 

// Now let dataChanged method be dispatched on every 

// incoming event* From now on every getValue () call 

// on this Remote will be rejected. 

status = rem2 . setCallbackObject (wp2) ; 

// call an appropriate main loop 

*/ 

* Client/server communication 
*/ 

CsaRemote <AbcWithPointers> rem3 ( n clsv_mode_conn" , 

CsaMscPeer : : PushMode) ; 
XyzSimpleClass sc3; // a simple user class 
AbcWithPointers wp3 (&sc3 ) ; // a container user class 
// Enable the dataChanged method 

wp3 .enblDataChanged( AbcWithPointers: : dataChanged) ; 

// First get some data using synchronous getValue () call 

status = rem3 .getValue (wp3) ; 

// Now let dataChanged method be dispatched on every 
// incoming event. From now on every getValue () call 
//on this Remote will be rejected, 
status = rem3 .setCallbackObject (wp3) ; 
// call an appropriate main loop 

} 



Although modifications and changes may be suggested by those skilled in the art, it is the intention of the inventors 
to embody within the patent warranted hereon all changes and modifications as reasonably and properly come within 
the scope of their contribution to the art 

Claims 

1 . An object oriented communication system on a computer platform, comprising: 

means for supporting external data representation without an interface definition language; 

means for propagating events in both push and pull communication modes and selecting which mode is used 

for a given connection; 

means for distributing events; and 

means for server processing pattern management. 

2. The object oriented communication system according to claim 1, wherein the means for supporting external data 
representation without an interface definition language comprises means for implicitly coding and decoding trans- 
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ferred data. 

3. The object oriented communication system according to claim 1 or 2, wherein atl communication end points that 
use the same address are logically connected. 

5 

4. The object oriented communication system according to claim 1 to 3, wherein there is provided a hook routine 
which called at the supplier side before data is sent and a hook routine which is called before data is stored in a 
target object, both hook routines called with an environment string as an argument, both hook routines influencing 
data transfer. 

10 

5. The object oriented computing system programmer interface according to claim 1 to 4, further comprising means 
for performing XDR encoding and decoding. 

6. The object oriented communication system according to claim 1 to 5, further comprising a macro routine which 
is makes a class accessible to a communication endpoint 

7. The object oriented communication system according to daim 6, wherein the macro routine makes the class acces- 
sible via the communication end point by declaring inserter and extractor operators of the communication systems 
internal encoder/decoder class as friends, and implementing short member functions and one member function 

20 pointer into the class. 

8. The object oriented communication system according to claim 1 to 7, further comprising a macro routine which 
defines a subset of data members that are to be transferred and informs the underlying system as to how to deal 
with pointers and vectors. 

25 

9. The object oriented communication system according to claim 8, wherein the macro routine has two arguments, a 
class name and a list of white space separated macro routines, one such macro routine for each transferable data 
member. 

30 10, The object oriented communication system according to claim 1 to 9, comprising a supplier class associated with 
a pattern string in order to transfer component classes to consumers associated with the same pattern string resid- 
ing on a host. 

11- The object oriented communication system according to claim 10, wherein the supplier class is a template class 
35 and can only exist in conjunction with a concrete component class. 

12. The object oriented communication system according to claim 1 to 1 1 , further comprising a consumer class asso- 
ciated with a pattern string in order to receive component classes in PUSH mode or PULL mode from suppliers 
associated with the same pattern string residing on hosts. 

40 

13. The object oriented communication system according to claim 12, wherein the consumer class is a template class 
and can only exist in conjunction with a concrete component class. 

14. An object oriented communication system programmer interface on a computer platform, comprising: 

45 

a first macro routine which makes a class accessible to a communication endpoint by declaring inserter and 
extractor operators of a communication systems internal encoder/decoder class as friends and implementing 
short member functions and one member function pointer into the Class; and 

a second macro routine which defines a subset of data members that are to be transferred and informs the 
so underlying system as to how to deal with pointers and vectors, a second macro routine having two arguments, 

a class name and a list of white space separated macro routines, one such white space separate macro routine 
for each transferable data member. 

15. The object oriented communication system programmer interface according to claim 14, comprising a supplier 
55 class associated with a pattern string in order to transfer component classes to consumers associated with the 

same pattern string residing on a host. 

16. The object oriented communication system programmer interface according to claim 14 or 15, wherein the supplier 
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class is a template class and can only exist in conjunction with a concrete component class. • 

1 7. The object oriented communication system programmer interface according to claim 14 to 1 6. further comprising a 
consumer class associated with a pattern string in order to receive component classes in PUSH mode or PULL 

s mode from suppliers associated with the same pattern string residing on hosts. 

18. The object oriented communication system programmer interface according to claim 14 to 17, wherein the con- 
sumer dass is a template class and can only exist in conjunction with a concrete component class. 

10 19. A storage medium including object oriented code for an object oriented communication system on a computer plat- 
form, comprising: 

means for supporting external data representation without an interface definition language; 
means for propagating events in both push and pull communication modes and selecting which mode is used 
15 for a given connection; 

means for distributing events; and 

means for server processing pattern management 

20. The storage medium according to claim 1 9, wherein the means for supporting external data representation without 
20 an interface definition language comprises means for implicitly coding and decoding transferred data. 

21 . The storage medium according to claim 19 or 20, wherein all communication end points that use the same address 
are logically connected. 

25 22. The storage medium according to claim 1 9 to 21 , wherein there is provided a hook routine which called at the sup- 
plier side before data is sent and a hook routine which is called before data is stored in a target object, both hook 
routines called with an environment string as an argument, both hook routines influencing data transfer. 

23. The storage medium according to claim 19 to 22, further comprising means for performing XDR encoding and 
30 decoding. 

24. The storage medium according to claim 19 to 23, further comprising a macro routine which makes a class acces- 
sible to a communication endpoint. 

35 25. The storage medium according to daim 24, wherein the macro routine makes the class accessible via the commu- 
nication end point by declaring inserter and extractor operators of the communication systems internal 
encoder/decoder class as friends, and implementing short member functions and one member function pointer into 
the dass. 

40 26. The storage medium according to claim 1 9 to 25, further comprising a macro routine which defines a subset of data 
members that are to be transferred and informs the underlying system as to how to deal with pointers and vectors. 

27. The storage medium according to claim 26, wherein the macro routine has two arguments, a dass name and a list 
of white space separated macro routines, one such macro routine for each transferable data member. 

45 

28. The storage medium according to claim 19 to 27, comprising a supplier dass associated with a pattern string in 
order to transfer component dasses to consumers associated with the same pattern string residing on a host. 

29. The storage medium according to claim 28, wherein the supplier class is a template class and can only exist in con- 
50 junction with a concrete component class. 

30. The storage medium according to claim 19 to 29, further comprising a consumer class associated with a pattern 
string in order to receive component classes in PUSH mode or PULL mode from suppliers associated with the 
same pattern string residing on hosts. 

55 

31. The storage medium according to claim 30, wherein the consumer class is a template class and can only exist in 
conjunction with a concrete component class. 
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32. A storage medium including object oriented code for an object oriented communication system on a computer plat- 
form, comprising: 

a first macro routine which makes a class accessible to a communication endpoint by declaring inserter and 
extractor operators of a communication systems internal encoder/decoder class as friends and implementing 
short member functions and one member function pointer into the class; and 

a second macro routine which defines a subset of data members that are to be transferred and informs the 
underlying system as to how to deal with pointers and vectors, a second macro routine having two arguments, 
a class name and a list of white space separated macro routines, one such white space separate macro routine 
for each transferable data member. 

33. The object oriented communication system programmer interface according to claim 32, comprising a supplier 
class associated with a pattern string in order to transfer component classes to consumers associated with the 
same pattern string residing on a host. 

34. The storage medium according to claim 33, wherein the supplier class is a template class and can only exist in con- 
junction with a concrete component class. 

35. The storage medium according to claim 33 or 34, further comprising a consumer class associated with a pattern 
string in order to receive component classes in PUSH mode or PULL mode from suppliers associated with the 
same pattern string residing on hosts. 

36. The storage medium according to claim 33 to 35. wherein the consumer class is a template class and can only exist 
in conjunction with a concrete component class. 
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